Voice communication over a packet-switched network using IP (Internet Protocol) is known as VoIP (Voice over Internet Protocol). For carrying multiple VoIP calls across an IP (Internet Protocol) network is to individually packetize each VoIP call and transmit it separately across the network. This means that each call has to carry the full IP header overhead, particularly the substantial IP/UDP (Used Datagram Protocol)/RTP (Real Time Protocol) header overheads, which leads to very poor bandwidth efficiency. In low bandwidth, high latency networks like satellite communication networks, such an overhead may cause efficiency and latency problems.
Several key current approaches—cRTP (compressed Real-time Transport Protocol, RFC2508 of the IETF), EcRTP (Enhanced cRTP, RFC3545 of the IETF) and ROHC (Robust Header Compression, RFC3095 of the IETF)—are known which attempt to improve the bandwidth efficiency by compressing the VoIP headers. However, all suffer from several key problems:
VoIP call interruption due to a loss of context at the decompressor.
The possibility of causing ‘Congestion Collapse’ due to the need to refresh the context at the decompressor with full, or partial, headers being retransmitted from the compressor.
The inability to deal efficiently with the loss, or misordering, of IP packets between the compressor and the decompressor.
In the following, the issues of these known approaches for improving bandwidth efficiency are explained in detail.
cRTP (RFC 2508)—The key issue with Compressed RTP is that if the base header context at the decompressor is lost then it must request full headers to be sent by the compressor, and whilst it is awaiting this new context, it must discard all VoIP packets, as it is unable to reliably decompress the IP headers for these packets. This causes the following key problems in the area of the invention:
Where the RTT (Round Trip Time) is considerable, e.g. Satellite links, the period of discard; whilst the updated context is awaited could be very substantial, >0.5 seconds. Clearly this will have a major effect on the quality of the voice call(s).
The response of this method to request full headers to be sent by the compressor for all the effected voice calls is extremely likely to cause a form of ‘Congestion Collapse’ to occur.
Although this method can be used with both IPv4 (IP version 4) and IPv6 VoIP calls, it cannot be used with both simultaneously, e.g. IPv4 VoIP phone to an IPv6 VoIP phone, which is a condition which is very likely to occur in the future as networks migrate from IPv4 to IPv6.
Implementations of the cRTP protocol are known to be very processor intensive and therefore it is highly likely that this would cause capacity issues in the area of the invention where multiple calls are to be supported simultaneously.
EcRTP (RFC 3545)—Enhanced Compressed RTP attempts to deal with the ‘Loss of Context’ issue in cRTP by transmitting all header changes N+1 times, where N is a characterisation of the quality of the link. This causes the following key problems in the area of the invention:
The selection of a suitable value for N is very difficult where a variable transmission medium is concerned, e.g. Satellite links, and this is likely to result in either excessive bandwidth wastage, where N is too high or repeated loss of context, where N is too low. Both conditions are likely to cause a form of ‘Congestion Collapse’ to occur.
Even if a suitable value for N is determined, and maintained, there is no guarantee in this method that the context will not be lost.
Although this method can be used with both IPv4 and IPv6 VoIP calls, it cannot be used with both simultaneously, e.g. IPv4 VoIP phone to an IPv6 VoIP phone, which is a condition which is very likely to occur in the future as networks migrate from IPv4 to IPv6.
As implementations of the cRTP protocol are known to be very processor intensive, given the changes for EcRTP it is very likely that it will be the same. Given this it is highly likely that this would cause capacity issues in the area of the invention where multiple calls are to be supported simultaneously.
ROHC (RFC 3095)—Robust Header Compression uses detailed knowledge about the fields in IP, UDP and RTP headers to identify the optimum data to be transferred, in order to keep the contexts current. This causes the following key problems in the area of the invention:
Although this complex protocol can deal with minor losses of context, there are still cases where it will be necessary to request an updated full, or partial, header from the compressor. As before if the compressor and the decompressor are linked via a high latency bearer, this is likely to have an effect on the voice quality of the effected voice call(s).
As ROHC was primarily designed for Cellular links, one of its primary assumptions is that the channel between the compressor and decompressor must maintain packet ordering, this assumption cannot be guaranteed in a normal IP network.
Although this method can be used with both IPv4 and IPv6 VoIP calls, it cannot be used with both simultaneously, e.g. IPv4 VoIP phone to an IPv6 VoIP phone, which is a condition which is very likely to occur in the future as networks migrate from IPv4 to IPv6.